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PREPAID CHARGING IN COMMUNICATION NETWORK 
FIELD OF INVENTION 

5 

This invention relates to charging in communication 
networks, especially third generation (UMTS) networks. 

The invention has been developed for use as an extension 
10 to the Diameter protocol defined by the Internet 
Engineering Task Force (IETF) , and will be described 
hereinafter with reference to this application. However, 
it will be appreciated that the invention can be applied 
to other similar protocols. 



BACKGROUND OF INVENTION 



Internet Protocol (IP) data transmission is used 
extensively in third generation (3G) networks. However, 

20 IP-related charging protocols and systems are not 
necessarily capable of providing all the functionality 
that would be desirable in a^ .mobile telecommunications 
scenario. Of particular concern is the wide acceptance 
and use of pre-paid accounts in relation to mobile 

25 telephones. Such prepaid accounts are not dealt with in 
existing IP-related charging systems, largely because IP- 
communications are, for the most part, not based on 
prepaid accounting systems. The problem is exacerbated 
by the unique nature of the signalling and call set-up 

30 routines employed in 3G networks, which have no direct 
correspondence with, for example, internet access via 
land-based computers . 
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A protocol known as Diameter has been proposed for use in 
IP networks. Diameter provides a base protocol that can 
be extended in order to provide AAA (Authentication, 
Authorization and Accounting) services. The base 

5 protocol is not intended to be used by itself, and must 
be used with a Diameter application. Diameter accounting 
is part of the base protocol and is therefore not 
intended for use without a Diameter application. 

10 Diameter can provide two types of service to 
applications. The first involves authentication and 
authorization, with optional accounting functionality. 
The second involves just accounting. 

15 Diameter accounting is based on a server directed model 
with capabilities for real-time delivery of accounting 
information. This means that an instance that generates 
charging data gets information from either the 
authorization sever (if contacted) or the accounting 

20 server regarding the way accounting data is to be 
forwarded. 

The Diameter accounting protocol provides real-time 
accounting, meaning the processing of information on 
25 resource usage within a defined time window. Time 
constraints are typically imposed to limit financial 
risk. 

Diameter does not presently provide for on-line charging. 
30 However, next generation cellular network specify a 
number of requirements and desirable features for on-line 
charging. Accounting servers in such networks must be 
able, for example, to check a subscriber's account for 
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coverage of the requested service prior to execution of 
that service. The subscriber's account must be debited 
each time the subscriber uses the services related to 
that account. Subscriber must also be prevented from 
5 accessing chargeable events or services related to their 
specific accounts once the account credit is exhausted or 
expired . 

It is also desirable to allow a mechanism for indicating 
10 to the subscriber the charges to be levied for a 
chargeable event. Also desirable is the ability to 
handle multiple charging scenarios, in which different 
combinations of network entities are simultaneously (or 
at least during a single call or data generating charges 
15 in relation to the subscriber's account. 

It is an object of the invention to provide a method of 
charging to a prepaid account within a network. 

20 SUMMARY OF INVENTION 

In a first aspect, the present invention, provides a 
method of charging against prepaid credit in 
communication network, the method comprising the steps 
25 of: 

requesting establishment of a call between a first 
terminal and a second terminal ; 

ascertaining whether any costs generated by 
accounting clients in the network, and associated with 
30 the call, are to be charged against prepaid credit; 

in the event some or all of the costs are to be 
charged against prepaid credit, establishing an 
accounting session between an accounting server and the 
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accounting client that will generate the costs to be 
charged against the prepaid credit, the accounting 
session being allocated an accounting session identifier; 
establishing the call with the second terminal; 
sending charging update data from the accounting 
client to the accounting server during the call; and 

collating the charging update data in the accounting 
server on the basis of the accounting session identifier, 
thereby enabling updating of the prepaid credit during 
the call . 

Preferably, there are a plurality of accounting clients 
that generate costs in relation to the call . In that 
case, accounting sessions are established between each 
15 respective accounting client and the accounting server, 
each of the accounting sessions being allocated a common 
accounting session identifier associated with the call to 
be established. Charging update data, including the 
accounting session identifier, are sent from each of the 
20 accounting clients to the accounting server during the 
call. The charging update information is collated in the 
accounting server on the basis of the accounting session 
identifier, thereby enabling updating of the prepaid 
credit during the call. 

25 

In a second aspect, the present invention provides 
communication network apparatus configured to allow 
charging against prepaid credit in relation to a first 
terminal, the network including an accounting server and 
30 an accounting client capable of generating costs 
associated with a service in the network, the network 
being configured to: 
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accept a request from the first terminal for 
establishment of a call between the first terminal and a 
second terminal; 

ascertain whether any costs generated by accounting 
5 clients in the network, and associated with the call, are 
to be charged against prepaid credit; 

in the event some or all of the costs are to be 
charged against prepaid credit, establish an accounting 
session between the accounting server and the accounting 
10 client that will generate the costs to be charged against 
the prepaid credit, the accounting session being 
allocated an accounting session identifier; and 

establish the call with the second terminal; 

wherein the accounting client is configured to send 
15 charging update data to the accounting server during the 
call; and 

the accounting server is configured to collate the 
charging update data on the basis of the accounting 
session identifier, thereby enabling updating of the 
20 prepaid credit during the call. 



As with the first aspect, it is preferred that multiple 
accounting clients exist within the network, and are 
configured to establish accounting sessions with the 
25 accounting server for relaying charging update data 
during the call. 



In both aspects, each accounting client preferably takes 
the form of one of the following network entities: 
30 SGSN/GGSN; 

S-CSCF/P-CSCF; and 

a network application server. 
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Typically, the accounting session identifier will be 
allocated upon receipt in the network of the request for 
establishment of a call from the first terminal. 

5 Preferably, the request for establishment of a call is 
made via a Session Initiation Protocol (SIP) message sent 
from the first terminal. 

It is particularly preferred that the charging update 
10 data is sent from the accounting clients to the 
accounting server via a Diameter protocol message. More 
preferably, the charging update data is sent from each 
accounting client to the accounting client in response to 
a Diameter protocol update request issued by the 
15 accounting server. 

In the preferred embodiment, the accounting server issues 
the update requests to each accounting client 
periodically. 

20 

BRIEF DESCRIPTION OF DRAWINGS 

A preferred embodiment of the invention will now be 

described, by way of example only, with reference to the 
25 accompanying drawings, in which: 

' Figure 1 is a functional block diagram of a third 

generation communication system; 

Figure 2 illustrates data flow between entities of 

the system of figure 1; and 
30 Figure 3 shows the flow of SIP and Diameter protocol 

data within the network, in accordance with the 

invention . 
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DETAILED DESCRIPTION OF PREFERRED AND OTHER EMBODIMENTS 

Referring to the drawings, the preferred embodiment of 
the invention is implemented by way of a single third 
5 generation communication network 31, having a core 
network section and other peripheral network units- Only 
the units that are pertinent to the present description 
are shown in Figure 1. In particular, the description 
that follows refers mainly to messaging and data flow 

10 that relates to establishment and implementation of 
accounting data for the purpose of charging a prepaid 
account. It will be understood that other messages and 
data are transmitted within the network to enable 
establishment of the call or data link, but these are 

15 well known in the art and have been omitted for clarity. 
It will also be appreciated that the word call is used in 
a broad sense within this specification and claims to 
include any type of channel or link that a user wishes to 
open, including video, image and sound channels, whether 

20 two-way or, uplink or downlink only. 

The network core includes a GGSN (Gateway GPRS Support 
Node) 32, an SGSN (Serving GPRS Support Node) 33, a P- 
CSCF (Proxy Call Service Control Function) 34, an S-CSCF 

25 (Serving Call Service Control Function) 35, an I-CSCF 
(Interrogating Call Service Control Function) 36 an 
Accounting Server/Credit Control Server (ACC/CCS) 37 and 
an Application Server (AS) 38. It will be appreciated 
that the ACC/CCS is specified in drafts of the Diameter 

30 IP protocol. However, the ACC/CCS can also be considered 
a Charging Control Point (CCP) incorporating a Charging 
Control Function (CCF) . In other words, they act as a 
prepaid server. 
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A first terminal in the form of a caller UE 30 is within 
the network service area and is attempting to establish a 
call to a second terminal in the form of a receiving UE 
5 39. The user of the first terminal has previously 
established a prepaid credit account with the network 
service provider. The intention of prepaid credit 
account is to ensure that a user cannot incur costs that 
have not been prepaid. In this way, users are not 
10 surprised by large bills that can come about in post-paid 
situations, and the service providers can offer service 
without the need for investigating the credit -worthiness 
of a user. 

15 For clarity, the actual details of the call establishment 
with caller UE 30 will be omitted, other than as they 
relate to the accounting procedures that relate to the 
invention. Similarly, the general functions of most of 
the units in Figure 1 are well known and will not be 

20 described in detail here. 

The network of Figure 1 is an all -IP (internet protocol) 
network. In the illustrated case, it is assumed that the 
network is the caller UE 30 subscriber's home network and 

25 that the receiver UE 3 9 is also located within the same 
network, for the purposes of simplicity. However, it 
will be readily be understood by those skilled in the art 
how the preferred embodiment can be extended to cover 
situations in which either or both of the UEs 30 and 39 

30 are not within the home network of the UE 30 (ie, one or 
both of the UEs are "roaming"). Such a scenario is 
described in the context of post-pay accounting in the 
applicant's UK patent application number 0112202.7. 
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It will also be understood that the particular components 
shown within Figure 1 can be distributed across a number 
of networks. Again, the way in which this can be 
5 achieved will be well understood by those skilled in the 
art, and so is not described in detail here. 

In general terms, the S-CSCF of a subscriber's home 
network acts to collect notices of charges levied for the 
10 activities of a subscriber to that network, or as a 
gateway to a unit that does so. The CSCFs of the system 
of Figure 1 operate so as to facilitate charging in the 
system, as will now be described in detail. 

By way of a simple overview of the invention, Figure 3 
shows the way in which SIP data flow horizontally between 
network entities within the different domains, whilst 
accounting data flows vertically and uses the Diameter 
protocol . 

When the user of UE 3 0 wishes to establish a call to UE 
39, the following steps take place. 

1. The user of UE 30 initiates the call, causing 
25 terminal 30 to transmit an INVITE message to the S-CSCF 
35, requesting for the initiation of a call with UE 39. 
The signalling to establish the call itself is performed 
in the normal way. The S-CSCF 3 5 inserts the following 
information into the INVITE message: 

30 

GS_ID 
CG_ADDRESS 
ACC S ADDRESS. 
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The GS_ID is a global session ID, which is used to allow 
combining of different accounting sessions. CG_ADDRESS 
is the address of the default Charging Gateway. 
5 ACC_S_ADDRESS is the address of the default ACC/CCS 
server, which acts as a prepaid server. 

2. The S-CSCF 35 sends the following accounting request 
(Diameter) to the ACC/CCS 37: 

10 Accounting-Request : 

<Session-Id>= 1 

[Accounting-Record-Type] = START_PP 
[Accounting-Mult i- Session- Id] = GS_ID 
[Subscription- Id] = exists 
15 [Time-Stamp] = exists 

3. The ACC/CCS 37 sends the following Accounting -Answer 
(in Diameter protocol) to the S-CSCF 35. The ACC/CCS 37 
will do the tariffing and rating and money reservation 

20 from the actual account . 

Accounting -Answer : 
<Session-Id> = 1 

[Accounting-Record-Type] « START_PP 
[Accounting-Multi-Session-Id] = GS_ID 
25 [Accounting- Interim- Interval] = 30s 

[Subscription- Id] = exists 

4. The S-CSCF 35 sends an INVITE (SIP) to Application 
Server AS 38, including the following information: 

30 GS_ID 

CG_ADDRESS 
ACC S ADDRESS. 
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5. The AS 38 sends an Accounting-Request (Diameter) to 
the ACC/CCS 37, as follows. The AS 3 8 doesn't know the 
cost of its service. 

Accounting -Request : 
<Session-Id> = 2 

[Accounting-Record-Type] = EVENT_PP 
[Accounting-Multi-Session-Id] = GS_ID 
[Subscription- Id] = exists 
[Time- Stamp] = exists 
[Service-Parameter- Info] = exists 

6. The ACC/CCS 37 sends an Accounting -Answer (Diameter) 
to AS 38, as follows: 

Accounting -Answer : 
15 <Session-Id> = 2 

[Accounting-Record-Type] = EVENT_PP 
[Accounting-Multi-Session-Id] = GS_ID 

7. The AS 38 sends an INVITE (SIP) to S-CSCF 35 

20 

8. The S-CSCF 35 sends an INVITE (SIP) message to I- 
CSCF 36. 

9. The I-CSCF 36 sends a 200OK message (SIP) to S-CSCF 
25 35. 

10. The S-CSCF 35 sends a 200OK (SIP) to the 
subscriber's UE 30. 

30 11. The subscriber's UE 3 0 sends a secondary PDP context 
to GGSN 32 . 

12. The GGSN 32 sends an Auth Request to P-CSCF 34. 
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13. The P-CSCF 34 sends an Auth Response to GGSN 32, 
including the following information: 

GS_ID 
5 CG_ADDRESS 

ACC_S_ADDRESS . 

14. The GGSN 32 sends an Account ing- Request (Diameter) 
to ACC/CCS 37, as follows: 

10 Accounting-Request : 

<Session-Id> = 3 

[Account ing -Re cord -Type] = START_PP 
[Accounting-Multi-Session-Id] = GS_ID 
[Subscription- Id] = exists 
15 [Time- Stamp] = exists 



15. The ACC/CCS 37 sends an Account ing- Answer (Diameter) 
to GGSN 32. ACC/CCS 37 will do the tariffing and rating 
and money reservation from actual account. In this phase 
20 the session is about to be established so ACC/CSS 37 has 
been able to do final rating for GSN nodes (IMS , AS and 
GPRS combination effects to tariff/rate) . 



The accounting answer is as follows: 
25 Account ing -Answer : 

<Session-Id> = 3 

[Accounting-Record-Type] = START_PP 
[Account ing -Multi -Session- Id] = GS_ID 
[Accounting- Interim- Interval] = 30s 
30 [Subscription- Id] = exists 



16. ACT secondary PDP context accepted from GGSNs to UE 
30. 
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17. COMET (SIP) from UE 30 to S-CSCF 35. 

18. Accounting -Request (Diameter) from S-CSCF 35 to 
5 ACC/CCS 37, as follows: 

Accounting -Request : 
<Session-Id> = 1 

[Accounting -Record- Type] = UPDATE_PP 
[Accounting-Multi-Session-Id] = GS_ID 
10 [Subscription- Id] = exists 

[Time-Stamp] = exists 

19. Accounting-Answer (Diameter) from ACC/CCS 37 to S- 
CSCF 35. 

ACC/CCS 37 will do the tariffing/rating and money 
reservation from actual account. The accounting answer 
is as follows : 

Accounting -Answer : 
<Session-Id> = 1 

[Accounting -Record- Type] = UPDATE_PP 
[Account ing-Multi -Session- Id] = GS_ID 
[Accounting- Interim- Interval] = 9 0s 
[Subscription-Id] = exists 

NOTE: Steps 20-23 are only undertaken if AS is not in 
one-time mode. 

20. COMET (SIP) from S-CSCF 35 to AS 38. 
30 

21. Accounting-Request (Diameter) from AS 38 to ACC/CCS 
37. 
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22. Accounting ^Answer (Diameter) from ACC/CCS 37 to AS 
38. 

23. COMET (SIP) from AS 38 to S-CSCF 35. 

5 

24. COMET (SIP) from S-CSCF 35 to I-CSCF 36. 

25. 200OK (SIP) from I-CSCF 36 to S-CSCF 35. 

10 26. 200OK (SIP) from S-CSCF 35 to UE 30. 

The protocol being used in the example is the AAA 
(Authentication, Authorization and Accounting) extension 
of the Diameter IP protocol. Currently with the existing 
15 Diameter solution there is no difference between post- 
paid and prepaid accounts. To enable handling of prepaid 
accounts in accordance with the preferred embodiment, the 
AAA extension has been modified to include the following 
record types: START_PP, STOP_PP, EVENT_PP and UPDATE_PP. 

20 

The first three record types correlate generally with the 
START, STOP and EVENT record types already in use in the 
protocol. However, there is no record type currently 
proposed or in use that corresponds with the UPDATE 
25 record type described above. The purpose of the new 
UPDATE record type is to allow polling of the various 
accounting clients by the ACC/CCS. 



The UPDATE record type can be used to change the tariff 
30 of the already established session. This functionality is 
needed when different domains interact with each other, 
such as when actions within the PS affect the IMS domain 
charges. In current IETF drafts this factor has not been 
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taken into account. The absence of an update function 
within the present proposed protocol means it is not 
possible to update ongoing accounting sessions, and so 
sponsorship-like charging plans or any other more 
complicated charging plans can not be implemented. 
In each case, the new _PP extension makes it clear to the 
entities that are receiving the record types that they 
are related to prepaid accounts, which must be treated 
differently to post-paid accounts. This new extension 
distinguishes post and prepaid mechanisms, thereby 
decreasing the signalling load. The new extensions 
distinguish post and prepaid mechanisms, thereby 
decreasing the amount of logical functionality needed in 
the server side . 

Once the steps listed above have taken place and been 
acknowledged, traffic data can be transferred between UEs 
3 0 and 39, in this case via the GGSN 32. 

20 A single third generation network may include a number of 
e l emen ts that can generate charging data that are 
relevant to the invention. These may be members of the 
IMS (IP multimedia subsystem) of the network, for 
instance the P-CSCF, S-CSCF, I-CSCF, BGCF (breakout 

25 gateway control function) and MGCF (multimedia gateway 
control function) , or members of the PS (packet -switched) 
domain, for instance the SGSN and GGSN. The charging 
data generated by the IP and PS domains may include 
different data. For example, a CDR generated by the GGSN 

30 (known as a G-CDR) typically includes information on the 
amount of packet -switched data transferred during the 
call, since the tariff for a packet-switched connection 
may be based on the amount of data transferred; whereas 
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charges generated by the P-CSCF may include information 
on the time taken for the call, since the tariff for an 
IP connection may be based on that factor. If a call 
makes us of both IP and PS connections then it is 
5 possible that multiple charging data may be generated for 
the call, and the result of this may be that a user is 
charged twice for the same call. To avoid this, the 
network may be arranged so that the IP and PS domains of 
the network cooperate so that charging data is not 
10 duplicated in this way. 

A similar addition to charging information may be used in 
case of other applications too, suitably for content- 
based charging purposes . 

15 

As an alternative, the GGSN may also indicate to the P- 
CSCF that it will generate charging data. In that case 
there would be no need to create such data in the IP 
multimedia subsystem itself. 

20 

Although the invention has been described with reference 
to a number of specific examples, it will be appreciated 
by those skilled in the art that the invention can be 
embodied in many other forms . 
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